Subject: Managing Costs in an APPN/ATM network

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 6 Nov 1995 17:10:00 -0500

The current model for APPN's use of ATM is for the ATM network to be defined
as a set of connection networks.  This is to represent the different levels
of cost and quality of service which will be provided by an ATM network which
includes both campus and wide area portions.  However regardless of the
details, the implicit assumption in this model was that if the end points of
a session are both connected to the ATM network a direct virtual channel
between them should be used, even if that requires establishing a switched
virtual channel.  Indeed IBM is so fond of this approach that they have
proposed establishing separate virtual channels in each direction.

This approach assumes that virtual channels are free.  They are not.  In an
ATM WAN there will be connect time charges to represent the resources which
are tied up in intermediate ATM switches.  In the ATM campus network the
switches will support a fixed number of virtual channels, and adding
additional VCs will inevitably require upgrading these switches.

On the other hand the proposal rightly points out that once we have created
those ATM cells we do NOT want to run up and down additional protocol stacks
at intermediate points if we can avoid it because that will increase the cost
of the intermediate switches, and increase delays through PIU reassembly.

Focussing on controlling costs on the WAN we consider the fairly common
situation where there are a small number of campuses each containing a large
number of end-points.  If the customer subscribes to one virtual path between
each pair of campuses additional virtual channels will not be visible to the
WAN carrier, and there will therefore be no additional carrier cost to the
establishment of a VC.  Virtual Paths are a scarce resource in the ATM
network, so the tariff may be very high for this configuration.  On the other
hand the functionality required of the carrier network is less, so the
carrier's equipment costs may be lower.  This solution will almost certainly
be ideal for very large locations, where OC-3 or higher access is required,
and therefore virtual paths would be required in any event.  I suspect that
at some lower level on the size scale this technique will become
uneconomical.

Another option, within the proposal, is to place an HPR capable network node
at the boundary between the campus ATM and the WAN ATM clouds.  In this case
no direct route is found between end points in one campus and those in
another.  All of the routes chosen for sessions between these end points will
pass through the APPN NNs which act as HPR gateways.  One concern expressed
at the AIW was that these gateways become very complex, and therefore
expensive.  The actual HPR data path is perhaps reasonable through these
modules, but the complexity of the CP services stacks on top is perhaps more
than some customers would wish to have.  In one mode this gateway does not
actually perform route calculations, since it has no LUs, and no end nodes
attach directly to it.  In that case why should it maintain a copy of the NN
topology database?  Perhaps it could be implemented as an HPR routing server
actually managed by another NN, something along the lines of the composite
network node.  On the other hand since the WAN ATM network provides the ideal
dynamic connection between independent APPN networks, this gateway box should
perhaps be an extended border node?  But that is another subject.

Many of the members of the AIW have LAN gateway boxes in their product line.
DLSw is a formalization of such a LAN gateway.  It is natural to therefore
propose that an APPN ATM gateway would also be a desireable product.  The
most obvious aspect of the existing proposal which interferes with this is
the proposed encapsulation of HPR inside ATM.  This proposal does not permit
multiplexing HPR LLC connections inside a single virtual channel.  I have
never quite understood why this was proposed on Frame-Relay, or why it
continues to be insisted upon on ATM.  As far as ISR goes, the injunction
against multiplexing, that is against using any SAPs other than 04-04, has
been pretty much ignored by the industry, and IBM has had to go back and
modify their existing implementations to support this fact of life.  That is
IBM implementations of Frame Relay now support SAP multiplexing in the
so-called BNN encapsulation, and furthermore IBM has introduced the BAN
encapsulation to actually increase the degree of multiplexing which is
possible over a Frame-Relay VC.  It is therefore extremely puzzling when,
despite this experience, IBM reverts to insisting upon a single LLC
connection per Virtual Channel on ATM.  I'm sorry guys.  I don't write the
rules of the market.  If we do not permit multiplexing within a single
VC on ATM in this specification, then the marketplace will simply ignore the
specification and invent some kluge which may not be easily interoperable.
Even if we do not have an unassailable argument for why multiplexing is
necessary, it is foolhardy to assume that the market will never come up with
one.